Забираю почту с ящика провайдера. Для Pop3recv стоит интервал опроса 2 минуты (пробовал и 1 ставить), таймаут 60000 (по умолчанию).
За ночь набегает до 4000 писем (спамят нас активно), бывает, что этот завал "разгребается" и до глубокого вечера (+ дневные письма). Как бы ускорить процесс получения писем с прова? Скорость 10 мбс, вполне достаточная.
Может, сервак провайдера так медленно отдает?
Вот они, тормоза где. У вас какая версия PigMail работает?
А как проверку ускорить?
Это единственное. что нашел.. Оно? Ибо в настройках Pop3RECV про DNS вообще не упоминается
Да, а DNS там у вас правильный прописан? Может, всё дело в том, что сервер непонятно куда стучится?
"Верификация доменов:" отключил
Интервал опроса сократил до минуты, количество писем в ящике наконец-то начало уменьшаться. Спасибо.
Сегодня с утра включил обратно, настроив на другой DNS прова. Пока работает без тормозов, максимум, что видел — 3 секунды на подтверждение отправителя.
Все равно есть задержка. Количество писем за день нарастает, получается, что в ящике, к примеру, 2300 писем, за время их обработки (порядка получаса) валится еще 2400-2500. И так — по возрастающей. В итоге письма обрабатываются уже после 8 вечера, когда поток спама снижается. В итоге — под вечер один "пакет" писем обрабатывается 1,5 часа (что-то около 4000), но в этом пакете могут быть письма и с 3 часов дня, и только что пришедшие.Скорость у прова, конечно, не ахти, но хочется все это "подстегнуть". Ограничить количество писем в пакете — тоже не выход, ибо в пиковые часы скорость приема идет до 10 писем в секунду, проверка с интервалом в 1 минуту ведет к "снежному кому" в ящике. В итоге, письма со "срочными заказами" вместо 16-17 часов сваливаются в 19-20. В логах скорость проверки отправителя — не более 1 секунды.
}\ToEmailBlackList.txt
В нем есть и rambler и mail (не редактировал, он — по умолчанию..)
А где его включить? Он, в принципе, включен, ибо письма от рамблера и мэйла идут в карантин.
Или не туда копаю?
Рамблер, мэйл и подобные идут с флагом "1"
Эмпирическим путем вычислено, что при потоке 5 писем/сек сервак справляется нормально. А в "пиковые" моменты скорость доходит до 50 писем/сек — а это уже критическая масса. При приеме 300 писем на ящик валится около 700, минутная пауза (+ еще штук 300) и за получение имеющейся 1000 писем сваливается 1.5, а то и 2 к.
Пошаманил, отключил RBL — не помогает.
Задержка все-таки присутствует, т.е. письма все-таки на что-то проверяются. Где можно посмотреть?
И еще вопрос. Ящик у прова — 300 метров. При скорости в 10 мбс скачать его — дело нехитрое. Можно ли организовать, чтобы после получения списка писем с сервера, весь список скачивался к нам (проверка производилась уже на месте), а робот ждал следующей "партии"?
И в довесок — может ли исправить положение опция "конвейер"?
RBL при Pop3Recv не работает, потому как IP-адреса отправителя нет. Вообще отключены все проверки, где этот IP используется.
Проверка доменов отключена? Тогда длинный чёрный список, видимо... Сто тысяч строк всё-таки. Или чем-то другим придержало.
Новый сервис надо писать. Этот принципиально однопоточный. И всё равно выше головы не прыгнуть. Все внутренние проверки — это ресурсы сервера. Распараллеливание на два или четыре потока (сколько процессоров у вас система видит?) выигрыш по скорости даст, но не в два или четыре раза, файловая система одна, да и диски будут придерживать.
Нет, это опция протокола SMTP.
С точки зрения скорости и не должно ничего меняться.
Проверка доменов отключена, но задержка все-таки есть. Можно полный список опций, которые влияют на проверку? Пробегусь по всем.
Как понял, RBL можно пока оставить отключенным.
Черный список вернул, кстати, к исходнику. На момент написания предыдущего поста. Эффекта нет.
На что влияет "режим обучения"? В IMAP-спаме увидел письма без [spam] в теме — оно?
Т.е. проверкой занимается тот же робот, что и скачиванием?
Если для одного ящика, то это неправильно. Или POP-сервер отпинает всех, кроме первого присосавшегося, или они все будут качать одно и то же. Я оба варианта наблюдал.
Проверки адреса отправителя, выполняющиеся при работе Pop3Recv:
Нет. В режиме обучения отправителю не выдаётся отказ, если письмо классифицировано как спам. Вам по барабану, потому что отправитель уже ушёл.
Да, там всё на лету и последовательно, как и написано в журнале.
Де-факто идет так:
Итого на прием 105 писем ушло почти 5 минут.
За это время в ящике — 511 писем, плюс перерыв минута, итого — 721.
Это — на полчаса забора почты.
Видел случаи, когда письмо, классифицированное как спам, продолжало стучаться по списку получателей. А в списке — человек 10..
Рваная цитата, к сожалению. Приведите обработку одного письма — от TOP n 0 до ответа на DELE n. Выберите письмо с несколькими адресатами, так виднее будет.
Если письмо классифицировано как спам, то оно уже принято, взвешено, измерено, положено в долгий ящик и никуда стучаться не может. Либо у провайдера в ящике ещё копия лежала, либо вы о чём-то другом. Хотелось бы лог увидеть.
Попробуйте ограничить количество принимаемых за раз писем. Плагин при этом перерывов не делает, если ящик полностью выкачать не получается.
Количество подбирать опытным путем? Или есть рекомендации?
Сама проверка адреса прошла быстро, зато шапка письма перед этим тянулась целых две секунды. А там только анализ полей на лету...
Сравним:
Тут шапка приехала быстро, зато анализ адреса задержался.
Похоже, что тормозит не сам поток Pop3Recv, а его перебивают параллельно работающие потоки acSMTP и acIMAP (как минимум, ещё что-нибудь системное может вмешаться). Посмотреть бы ночной лог, когда пользователей нет.
Это нормально. Каждый получатель честно проверяется на право получать спам в собственный ящик.
С потолка: 300
Ещё ускорение даст понижение уровня оперативного журнала. В ущерб возможностям разбора полётов.
В это время пользователей точно не было.
Вчера пытался ограничиться 100 писем за раз — количество росло
Сегодня попробую с 30 (время приема — меньше минуты), посмотрим на результат.
Есть еще вопрос: при получении количества писем с сервака, они каким-то образом нумеруются/упорядочиваются. Принимаются, соответственно, от старшего номера к более младшему, по убыванию. При этом замечаю, что первыми принимаются более новые письма, хотя считаю это неправильным. Чем определяется эта последовательность?
Ограничение на количество писем проблему не снимет, оно просто исключит минутные ожидания. Чуть полегче будет.
Что до нумерации писем — номера присваивает сервер, а выборка от новых к старым просто проще в реализации была. Видимо, вы правы, надо по возрастанию номеров загружать.
Мне надо готовить оборудование, а я, вместо этого, отвлекаюсь на почту
А как поток Pop3Recv отображается в процессах? Я думал, что аcSMTP этим занимается..
А если таки 1.36, то лучше полную. Настройки все живут в CONF.pigmail, если не поменяли каталог, поэтому просто не перезаписывайте его.
P.S. Я завтра вечером отъезжаю в офлайн. Полный выход через месяц, но всплывать временами надеюсь уже числа после 15 октября.
С 5:30 работает бета7, 13700 писем за 25 минут скачалось (ночной клин был). Мониторю количество, пока — по ощущениям — процесс идет намного быстрее..
Результаты выложу в этом топике.
It's WORK